Object access level

ABSTRACT

A system for regulating access to information of different levels of sensitivity includes an input configured to receive authentication information from a user, and a processor configured to: produce a first token key; encrypt a read-write portion of a first cryptographic key associated with a first sensitivity level using the first token key; encrypt the first token key using first authentication information associated with the first sensitivity level; produce a second token key by applying a one-way function to the first token key; encrypt a read-write portion of a second cryptographic key associated with a second sensitivity level using the first token key, the second sensitivity level being lower than the first sensitivity level; and encrypt the second token key using second authentication information associated with the second sensitivity level.

CROSS-REFERENCE TO RELATED ACTIONS

This application claims the benefit of U.S. Provisional Application No.60/591,944 filed Jul. 29, 2004, which is incorporated here by reference.This application incorporates here by reference each of the followingapplications: U.S. application Ser. No. No. ______, entitled“Information Centric Security,” and bearing Attorney Docket No.23840-516, U.S. application Ser. No. ______, filed Jul. 29, 2005,entitled “Cryptographic Key Management,” and bearing Attorney Docket No.23840-517, and U.S. application Ser. No. ______, filed Jul. 29, 2005,entitled “Cryptographic Key Construct,” and bearing Attorney Docket No.23840-518.

STATEMENT AS TO FEDERALLY-SPONSORED RESEARCH

This invention was made at least in part with Government support underSTTR Contract No. N00014-04-C-0259, US Navy Office of Naval Research.

BACKGROUND

In today's dynamic, fast-paced environment, it is desirable to securelymanage the expeditious exchange of ever-increasing amounts of on-demandinformation within fluid Communities of Interest (COIs). COIs includeentities such as companies, agencies, organizations, and groups ofentities such as governments and militaries (e.g., branches within asingle government or between multiple governments). The InformationAssurance (IA) solution used preferably provides the capability ofsharing data (e.g., electronically) at the information/data object level(Information Centric Security or INFOCENSEC) across functions andorganizations throughout an enterprise while providing data separationand confidentiality.

While electronic communication has benefits, electronic communicationalso has concerns, particularly in the area of protecting itsconfidentiality, integrity and its authenticity. This is compounded whendealing with multinational entities or multiple entities such ascompanies, agencies, or organizations with various levels of trust thatdesire to share information securely. Access to the message (i.e.,plaintext information) is preferably controlled so that only thoseindividuals authorized with a “need-to-know” are granted access to theplaintext information.

Techniques for addressing electronic communication security exist today.One technique uses cryptography to provide privacy and data integrity.Cryptography involves the conversion of data into a secret code that caneither be transmitted over an electronic communication medium (e.g.,LAN, WAN, Internet, etc.) or stored on a memory device (e.g., harddrive, USB Fob, CD, etc.). The original text, or “plaintext,” isconverted into a coded equivalent called “ciphertext” at the producer(e.g., author) via an encoding device that incorporates an encryptionalgorithm with a predetermined sequence of steps. A plaintext is notnecessarily composed of text, but may include text or graphics or otherforms of information, and may be combinations of forms of information ora single form of information by itself. Many different algorithms existand each algorithm uses a string of bits known as a “key” to perform thecalculations. The larger the key (the more bits), the greater the numberof potential patterns can be created, thus making it harder to break thecode and descramble the contents. The data are encrypted, or “locked,”by combining the bits in the key mathematically with the data bits. Ifthe ciphertext message is intercepted (either during transit or at rest)by an unauthorized entity, the message is essentially worthless to theintruder, who does not possess the means to decrypt the encryptedmessage. Members of COIs often share information that has been encryptedto help ensure the safe transfer and storage of information. COI membersare members of cryptographic domains, with members of each domain usinga common set of cryptographic parameters for an encryption algorithm,e.g., which base values are used in cryptography.

On the receiving side (e.g., consumer) of an encrypted communication, adecoding device or decrypting engine is provided. The decoding deviceaccepts the ciphertext message and the same cryptographic key that wasused during the encryption process is used to decode (decrypt) theciphertext and turn it back into a plaintext message that corresponds tothe original message.

The manner in which the key and the algorithm are applied in acommunication process, and the manner in which the keys are managed,define a cryptographic scheme. There are many conventional cryptographicschemes in use today. The two most popular of these are public-keycryptography and Pretty Good Privacy (PGP). The keys used in theseschemes incorporate a combination of a public key component that isavailable to anyone who wants to encrypt (e.g., a producer) a message,and a private key component that is typically held by the recipient(e.g., a consumer) to decrypt the ciphertext back to the originalplaintext message.

There are a number of considerations for determining whether aparticular cryptographic scheme is desirable for the application inwhich it is to be used. For example, the following may be considered.

-   -   1. The degree of difficulty to defeat the cryptography. This        refers to the amount of effort required for an unauthorized        entity to decrypt the ciphertext message. To improve the        security of the cryptographic scheme is to reduce the likelihood        that a valid key can be stolen, calculated, or discovered (e.g.,        compromised). The more difficult it is for an unauthorized        entity to obtain a valid key, the more secure the cryptographic        scheme.    -   2. The means to dynamically add, update and/or revoke a member's        access (i.e., retract an entity's access privileges). Revocation        refers to preventing access to material encrypted subsequent to        revocation, even though access to material encrypted during a        member's period of legitimate access may not be stopped. Once        the decision to revoke (i.e., to remove access to some portion        of the member's access or completely remove the member from        accessing any/all protected data) is made, new        encryption/decryption access denial should be as complete and        rapid as security risks warrant. The timeliness of distributing        entity updates/revocation may greatly affect the security of the        cryptographic scheme.    -   3. Whether the cryptographic key management scheme supports        cross-domain (e.g., different cryptographic domains) information        sharing and can provide persistent access control to the        cryptographic keys for the ciphertext message. The assured        information-sharing cornerstone is to provide the ability to        dynamically share information at multiple sensitivity (e.g.,        classification) levels among various entities such as countries,        organizations, agencies, etc. Information access may be based on        mission need, information sensitivity, entity's identity and        privileges, and level of protection provided by an entity's        environment.    -   4. Scalability. There are many aspects of scalability to be        considered in evaluating key management systems, such as:        Generation, distribution, revocation and recovery of keying        material; re-key interval (i.e., crypto period); updating and        maintaining keys for users including users changing roles within        a community of interest (COI) as well as        adding/changing/revoking of access requirements, e.g., on an        as-needed basis; COI interoperability, including multiple        nations as well as cooperative COIs; access control to content        at the object level; and support for dynamic resource        management.

SUMMARY

In general, in an aspect, the invention provides a system for regulatingaccess to information of different levels of sensitivity, the systemincluding an input configured to receive authentication information froma user, and a processor configured to: produce a first token key;encrypt a read-write portion of a first cryptographic key associatedwith a first sensitivity level using the first token key; encrypt thefirst token key using first authentication information associated withthe first sensitivity level; produce a second token key by applying aone-way function to the first token key; encrypt a read-write portion ofa second cryptographic key associated with a second sensitivity levelusing the first token key, the second sensitivity level being lower thanthe first sensitivity level; and encrypt the second token key usingsecond authentication information associated with the second sensitivitylevel.

Embodiments of the invention may provide one or more of the followingfeatures. The processor is further configured to: decrypt the firsttoken key using the first authentication information; and decrypt theread-write portion of the first cryptographic key using the decryptedfirst token key. The processor is further configured to: decrypt thesecond token key using less than all of the first authenticationinformation; and decrypt the read-write portion of the secondcryptographic key using the decrypted second token key.

In general, in another aspect, the invention provides a computer programproduct for regulating access to information of different levels ofsensitivity, the computer program product including computer-readableinstructions configured to cause a computer to: receive authenticationinformation from a user; produce a first token key; encrypt a read-writeportion of a first cryptographic key associated with a first sensitivitylevel using the first token key; encrypt the first token key using firstauthentication information associated with the first sensitivity level;produce a second token key by applying a one-way function to the firsttoken key; encrypt a read-write portion of a second cryptographic keyassociated with a second sensitivity level using the first token key,the second sensitivity level being lower than the first sensitivitylevel; and encrypt the second token key using second authenticationinformation associated with the second sensitivity level.

Embodiments of the invention may provide one or more of the followingfeatures. The computer program product further includes instructionsconfigured to cause the computer to: decrypt the first token key usingthe first authentication information; and decrypt the read-write portionof the first cryptographic key using the decrypted first token key. Thecomputer program product further includes instructions configured tocause the computer to: decrypt the second token key using less than allof the first authentication information; and decrypt the read-writeportion of the second cryptographic key using the decrypted second tokenkey.

In general, in another aspect, the invention provides a method ofcontrolling access to sensitive information, the method includingobtaining a first token key, receiving first authentication informationassociated with a first sensitivity level and second authenticationinformation associated with a second sensitivity level that is lowerthan the first sensitivity level and thus indicative of less-sensitiveinformation, encrypting a read-write portion of a first cryptographickey associated with the first sensitivity level using the first tokenkey, encrypting the first token key using the first authenticationinformation, producing a second token key by applying a first one-wayfunction to the first token key, encrypting a read-write portion of asecond cryptographic key associated with a second sensitivity levelusing the first token key, and encrypting the second token key usingsecond authentication information associated with the second sensitivitylevel.

Embodiments of the invention may provide one or more of the followingfeatures. The method further includes producing a third token key byapplying a second one-way function to the second token key, receivingthird authentication information associated with a third sensitivitylevel that is lower than the second sensitivity level, encrypting aread-write portion of a third cryptographic key associated with thethird sensitivity level using the third token key, and encrypting thethird token key using the third authentication information. The firstone-way function is a cryptographic hashing function and the secondone-way function is the same function. The second authenticationinformation and the third authentication information are portions of thefirst authentication information. Receiving the second authenticationinformation and receiving the first authentication information areincluded in receiving the first authentication information. The methodfurther includes re-receiving the second authentication information, andinhibiting access to the first token key. The method further includesdecrypting the second token key using the re-received secondauthentication information, and decrypting the read-write portion of thesecond cryptographic key using the decrypted second token key. Themethod further includes re-receiving the first authenticationinformation, decrypting the first token key using the firstauthentication information, decrypting the read-write portion of thefirst cryptographic key using the decrypted first token key, decryptingthe second token key using a portion of the re-received firstauthentication information, and decrypting the read-write portion of thesecond cryptographic key using the decrypted second token key.

In accordance with implementations of the invention, one or more of thefollowing capabilities may be provided. A cryptographic key managementsolution may be difficult to defeat, allow for dynamic additions,updates, and/or revocations, provide scalability, support cross-domaininformation sharing with persistent access control to cryptographickeys, and support cross-domain capabilities without inducing managementoverhead by requiring entity in a COI to manage members of entity of theCOI. It is therefore an object of this invention to provide a processand apparatus for assembling keys that provides added security againstcompromising a communication by unauthorized entities. Key componentsmay be generated, distributed, and controlled within a cryptographic keymanagement scheme that facilitates secure cross-domain communicationsharing while maintaining data separation on a need-to-know basis forauthorized users within a predetermined COI. Key material may beestablished, managed and distributed among disparate entities for bothsmall ad hoc COIs as well as large COIs involving many entities withoutcreating management overhead of members by any one entity. Keycomponents may be developed within a cryptographic key management schemethat enables an assured dynamic and timely update and/or revocation ofindividual member privileges so that the member is afforded access toplaintext information substantially only during the time frame in whichthe member is authorized to do so. Key components may be developedwithin a cryptographic key management scheme that supports strategic aswell as tactical environments. In strategic environments, all membershave access to a network infrastructure LAN, WAN, Internet, etc.,whereas, in a tactical environment, members are separated/isolated froma network in a standalone environment. Key components may be developedwithin a cryptographic key management scheme that cannot be easilyreproduced by unauthorized parties. Cross-domain information sharing canbe supported and persistent content-based access control provided on adata object within a network-centric environment that supports atactical, client-only environment. Scalability is facilitated and singlepoint of failure DoS attacks can be mitigated.

Also in accordance with implementations of the invention, one or more ofthe following capabilities may be provided. Access privileges ofindividual members can be updated electronically over a network. Anindividual member/device (e.g., computing device such as sensors, PDA,laptop, etc.) or an entire organization, country, agency, etc. can beremoved from continuing or future access to information/resources. Whohas access to what information can be closely controlled. Dataseparation can be achieved, e.g., through creation, support,reconfiguration and/or revocation of multiple communities of interest(COIs). Dynamic COIs can be established and maintained. Accessprivileges can be authenticated and distributed to individual members ofan organization using various identity-based key management systems(e.g., PKI). A cryptography solution is scalable and usable forinformation centric data protection, specifically for data at rest.Distribution and maintenance of information access can be significantlyenhanced. More efficient, scalable and adaptive key management solutionscan be provided.

Also in accordance with implementations of the invention, one or more ofthe following capabilities may be provided. Object use in a network canbe monitored (e.g., constantly) to provide feedback on informationdissemination. User roles/labels can be dynamically updated, e.g., basedupon usage and need-to-share. Information can be pushed to and/or pulledfrom selected individuals/systems. Roles/labels can be updated basedupon monitored activity. Problems/vulnerabilities can be identifiedbased upon monitored activity. Amounts of information a person can workwith at one time can be increased. Time to review, analyze, andimplement labeling requirements for a role-based access control (RBAC)solution can be reduced. Management and dissemination ofintellectual/data assets can be enhanced. Users can rapidly discoverhidden information relationships from varying data sources.Unanticipated relationships of data can be identified and changes ininformation access examined. Analytical tools allowing members toinvestigate the Document groupings can be investigated, documentcontents queried, and trends, e.g., in access, investigated.

RBAC refers to a class of security mechanisms (e.g., metadata or labels)that mediate access to resources (e.g., data, applications, systems,devices, networks, etc.) through organizational identities, calledroles. Typically, the roles within an organization often relate to otherroles in terms of their capabilities or access privileges. Allowingadministrators to define roles with respect to other roles can improveefficiency and consistency—especially in organizations that have a largenumber of roles. Defining roles with respect to other roles can also beused to dynamically change member access privileges for changingsituations and/or events all based upon policy. Defining roles withrespect to other roles can also provide means to push to and/or pulldata from members based upon the content of the information as well asthe roles of the members.

These and other capabilities of the invention, along with the inventionitself, will be more fully understood after a review of the followingfigures, detailed description, and claims.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a diagram of a stove-piped security solution using separatenetworks.

FIG. 2 is a diagram of an information-centric security systemarchitecture.

FIG. 3 is a block diagram of computers shown in FIG. 2.

FIG. 4 is a block diagram of a communications event using cryptography.

FIG. 5 is a block flow diagram of a process of producing a cryptographiclabel.

FIG. 6 is a block flow diagram of a process of producing and storinglabel splits.

FIG. 7 is a block flow diagram of a process of dynamically updating andrevoking access privileges.

FIG. 8 is a block diagram illustrating sensitivity levels and access andauthentication for the levels.

FIG. 9 is a block flow diagram of a process of producing a keyencrypting key and encrypting a data encryption (working) key using thekey encrypting key.

FIG. 10 is a block diagram of a coalition for sharing data.

FIG. 11 is a block diagram of label importing and exporting.

FIGS. 12-13 are block flow diagrams of label importing and exporting.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Embodiments of the invention provide techniques for scalablecryptographic key management that supports cross-domain informationsharing. Embodiments of the invention provides techniques for generatinga key encrypting key (KeK), protecting, managing, and distributinglabels/cryptographic keys used to generate the KeK that is used tocontrol access to a working key used to encrypt plaintext messages/dataand decrypt ciphertext. For example, in key management system a privatecryptographic key and a public cryptographic key may be derived and usedto obtain a label. This label (either a sensitivity label or a categorylabel, as described below) can be parsed into pieces that are unique foreach user of the label and the unique pieces stored. The pieces can berecombined into the label. The label is used to generate a KeK that isused to encrypt a data encryption key in a key protection module. Thedata encryption key is used to encrypt plaintext data to produceciphertext and the encrypted data encryption key is put in a headeralong with the ciphertext. The encrypted data encryption key isdecrypted using the re-generated KeK and the data encryption key is usedto decrypt the ciphertext. This encryption system is exemplary, however,and not limiting of the invention as other implementations in accordancewith the disclosure are possible.

Referring to FIG. 1, historically, in “secure” information-sharingsolutions, such as a solution 10, with multinational, classified,information sharing, users have operated between segregated networks 12,14, 16, 18 of multiple security levels (MSLs). These stove-piped networkenvironments allow the user to send and receive information across asingle security level but use controlled interface devices (i.e., guardsor sanitizers) 20, 22, 24 to securely bridge the information flowbetween the disparate networks 12, 14, 16, 18. When a controlledinterface device is not available for the architecture (or for aspecific data type), users typically transfer information betweennetworks via hand-transferred media (air gap) or not at all.

The cross-domain controlled interface devices 20, 22, 24, commonly knownas guards, allow the exchange of data via secure and sometimes automatedmeans. Though the devices themselves may securely process information atmultiple levels simultaneously, and though these devices may be definedas Multi-Level Security (MLS) systems, they typically do not provide MLSwork environments. The segregated, single-level networks 12, 14, 16, 18,are separately maintained in MSL architecture. Unlike this stove-pipeapproach, an MLS network environment preferably stores and processesinformation of different security domains—allowing users to exchangeinformation only at levels they are authorized while denying access toinformation they are not cleared to see.

Referring to FIG. 2, a system (architecture) 30 for secure data storageand communication includes an administration system 32, a remoteadministration management console 34, and a client 36. The system 30 isreferred to as the Need2Know® system, or N2K™ for short. Theadministration system 32 can communicate with the console 34 through anetwork, here through a gateway 38, to interact with a network browserof the console 34. The console 34 and the client 36 can be computers asdescribed with respect to FIG. 3 below. The administration system 32 isconfigured to communicate with the client 36 to send the client AbridgedToken Repository (ATR) and Token Maintenance File (TMF) information,described more fully below. The client 36 includes a key protectionmodule (KPM) 420 (described more fully below with respect to FIG. 9) anda token device 37 such as a Department of Defense (DoD) Common AccessCard (CAC). The KPM 420 supports cross-domain information sharing andcan provide persistent content-based access control (CBAC) on a dataobject within a network-centric environment that supports a tactical,client-only environment using a secure parser function to split labelsinto substantially unusable cryptographic keys and storing them inspecified locations. The administration system 32 includes a web server39, an audit server 40, a management server 41, a database server 43,and a reporting server 45. The web server 39 is configured to exchangeinformation with the gateway 38 and the management server 41. The auditserver 40 is configured to monitor information stored in the databaseserver 43. The management server 41 is configured to interact andexchange information with the web server 39, the database server 43, thereporting server 45, and a full service directory 47 that useslightweight directory access protocol (LDAP). The management server 41includes computer software code instructions for causing a processor ofthe server 41 to perform operations described below. The components ofthe administration system 32 may be combined or distributed, e.g., forperformance, security, and/or redundancy considerations. In particular,the server 41 is configured to determine and distribute cryptographiclabels, to oversee the assignment of roles and to control accessprivileges of clients (e.g., members) based upon roles and securitylevels of clients, and to coordinate domains as described below. Eachorganization (e.g., country, agency, etc.) may have its ownadministration system 32 that coordinates the domain(s) within theirrespective organization and there may be at least one administrationsystem 32 or management server 41 that oversees groups (coalitions) ofdomains. Through the remote console 34, the administratorenrolls/registers members in domains, assigns members to organizationunits, controls member administration, and assigns roles to members.These are maintained in the database 43. The reporting server 45 isconfigured to provide reports regarding the cryptographic key managementadministrative information, e.g., in the form of HTML reports 49, PDFreports 51, and CSV (Common Separated Value) reports 53.

The system 30 provides a scalable cryptographic key management solutionfor cross-domain information sharing. The system 30 provides the KPM 420that incorporates strong, configurable identification, authentication,and authorization mechanisms, providing persistent access control on adata object in a network-centric environment while providing for adeployed tactical client-only environment. The system 30 furtherprovides specifications (e.g., open API) for header information, and ahierarchical administrative structure that is scalable and supports keymanagement/distribution across multiple cryptographic domains. Thesystem 30 further provides active auditing, through the audit server 40,of both client and administrative functions, and reporting of activitythrough the reporting server 45. The system 30 also protectsapplications/information with an application encapsulation techniquethat protects against, e.g., hackers and malicious code attacks in asoftware-based environment, that helps protect information in transit,at rest, and in process. Other embodiments of the system 30, however,are possible, including embodiments that provide fewer, more, and/ordifferent features than listed here.

Referring also to FIG. 3, each of the servers 39, 40, 41, 43, 45, theconsole 34, and the client 36 preferably includes a processor 46, memory50, one or more input devices 52, and storage 54, and may also include adisplay 48. The processor 46 can be a personal computer centralprocessing unit (CPU) such as a processor made by Intel® Corporation orAMD® Corporation, although processors made by other companies may beused and thus the invention is not limited to using processors made byeither of these companies. The display 48 is a cathode-ray tube (CRT),although other forms of displays are acceptable, e.g., liquid-crystaldisplays (LCD) including TFT displays. The memory 50 includes randomaccess memory (RAM) and read-only memory (ROM). The input device(s) 52may include a keyboard, mouse, floppy disk drive, CD-ROM, a USB Fob,and/or a biometrics sensor, etc. The input device(s) 52 provides fordata input by a user (not shown) and/or a token, e.g., to inputcryptography keys. The storage 54 may include a hard-disk drive, and caninclude floppy-disk drives, a CD-ROM drive, and/or a zip drive. Thecomponents 46, 48, 50, 52, and 54 are connected by a bus 56 forcommunication between the components. The server 41 and the client 36can store, e.g., in the memory 50, software code containing instructionsfor controlling the processor 46 to perform functions described below.In particular, the server 41 and the client 36 can store and/or processencryption keys or portions thereof, including labels and label splitsdescribed below. The client 36 can also encrypt information, transmitand/or store the encrypted information, and receive and/or retrieveencrypted information and decrypt the encrypted information.

In operation, referring to FIG. 4, with further reference to FIGS. 2-3,a process 70 for encrypting, transmitting and/or storing, and decryptinginformation using the system 30 includes the stages shown. The process70, however, is exemplary only and not limiting. The process 70 may bealtered, e.g., by having stages added, removed, or rearranged.

At stage 72, the communication originates at an origination space suchas the client 36. The origination space is the place and time at whichthe communication originates. At this stage, unencrypted information(plaintext) 80 is encrypted using an encryption key 82 by an encryptionor encoding device (encrypt text/key relation) 84 to produce encryptedinformation, i.e., ciphertext 86.

At stage 74, the ciphertext 86 is communicated to a destination space,being the time and place at which the communication is to be decoded.Stage 74 may comprise, e.g., transmitting the ciphertext 86 from theclient 36 to another computer without storing the ciphertext 86 (asidefrom caching the ciphertext 86 in network hops, for example) asindicated by an arrow 88. Alternatively, the stage 74 may comprisestoring the ciphertext 86 in a storage 90 as indicated by an arrow 92and retrieving the ciphertext 86 as indicated by an arrow 94. Forexample, the client 36 may store the ciphertext 86 in its memory 50 andretrieve it at a later time. Further, the stage 74 may comprise acombination of storing and transmitting, e.g., by having the client 36transmit the ciphertext 86 to a network storage device, and having theciphertext 86 later transmitted to the a destination space for decoding.

At stage 76, the ciphertext 86 is received by the destination space anddecoded/decrypted. An authorized entity applies a decoding device(decrypt text/key relation) 96 using a proper decryption key 98 todecrypt the ciphertext 86 to produce decrypted plaintext 81corresponding to (e.g, identical to) the input plaintext 80.

The origination space and the destination space may be disposed atremote locations (e.g., physically different ones of the computingdevices 40, 42, 44). Alternatively, the origination and destinationspaces may be collocated but displaced in time (e.g., the same physicalcomputing device 40). The space and time correspondence between theorigination space and destination space may vary depending on the natureof a particular communication. The origination space and the destinationspace are coupled to a common communications channel 89. Thiscommunications channel 89 may bridge a physical space, such as empty airin the case of cellular voice telephone call. Alternatively, thecommunications channel 89 may be the temporary storage 90 for thecommunication while time passes between the origination space and thedestination space. For example, the communication may be a message leftin the memory 50 of the client 36 by a first user for a second user toretrieve and read at a later time on the same client 36. As anotheralternative, the communications channel 89 may be used to place data inthe temporary storage 90 for the communication while time passes betweenthe origination space and the destination space, with the message beingleft in memory on a network storage device by a first user of the client36 for a second user to retrieve and read at a later time through thecommunications channel 89 on a different computing device at thedestination space. The communications channel 89 may also be acombination of the two, such as sharing communications through emailservices over the Internet or a LAN/WAN.

The origination space and the destination space can be, for example,computers (e.g., the computers 40, 42, 44), or even the same computer(e.g., the client 36). For example, the client 36 may store the text/keyrelation 84 and/or 96 in the memory 50. The processor (e.g., amicroprocessor or similar controller) 46, along with a control structureand the memory 50 (e.g., RAM) for storing original plaintext and keysprovided by a user, can be included in both the origination space andthe destination space and can perform the functions of the encryption 84and the decryption 96. The input device(s) 52 can accept the encryptionkey 82 and the plaintext message 80 from the origination user, and thedecryption key 98 and the ciphertext message 86 from the destinationuser. At the destination space, an output device, such as thedisplay/monitor 48, the disk drive 54, or the output device(s) 58 maypresent the decrypted plaintext message 81 to the destination user. Thetext/key relation 84 and/or 96 can be stored on a floppy disk or otherpermanent and/or temporary portable storage to facilitate differenttext/key relations 84 and/or 96 to be applied by different users and/orin different situations.

Other measures are preferably used to help keep the system 30 secure.For example, as an added level of protection, using the invention thedata encryption key 82 can also be encrypted. The encrypted dataencryption key (dek) 82 can be sent along with the ciphertext 86, e.g.,as a header associated with the ciphertext 86, to the destination. Theencrypted dek can be decrypted by an authorized destination and used todecrypt the ciphertext 86. Cryptographic keys are also periodicallychanged to help keep the system 30 secure. The system 30 caters not onlyto data in transit but also data at rest (e.g., computer file storage),and provides a method of key recovery. The ability to recover oldvalues, however, is constrained to go back only as far as authorized bythe administrative system 32 for a member using a backwards secrecyvalue, explained more fully below. Indeed, the system 30 can prevent orpermit recovery of old values entirely.

One-way functions (e.g., cryptographic hash algorithms) are used by theserver 41 to generate new keys from old. The one-way functions providemembers with a means to recover keys used in the past. The functionsalso provide administrators with a measure of control over key recoverywhile still retaining security.

When a label is produced, three values are generated at random: a basevalue (b), a backward controlling value (c) and a stepping key (s). Thebase value is concatenated with the stepping key and hashed to producethe private key. This is repeated f times where f is about 65,000(although other values of f may be used). This value is called b_(f).Concatenating b_(f) with c_(l), hashing this value and then reducing itmodulo q derives the first maintenance-level private key. The public keyis generated in the usual way from the private key.

Deriving subsequent key pairs proceeds by calculating b_((f−l+1)) andc_(l), where l is the maintenance step. The two values are concatenated,hashed, then reduced modulo q producing the private key for thatmaintenance step. The public key corresponding to this step iscalculated in the normal way.

In operation, referring to FIG. 5, with further reference to FIG. 2, aprocess 110 for determining a label 142 using the server 41 and theadministration database server 43 includes the stages shown. The process110, however, is exemplary only and not limiting. The process 110 may bealtered, e.g., by having stages added, removed, or rearranged. The labelincludes a named asymmetric key pair and can be distributed by theserver 41 to entities for encryption and decryption of deks.

The label 142 includes a human-readable portion 140 for ease of use andidentification by the user, and a machine-actionable portion 138 toprovide access control to label recipients. Here, labels are used withan ephemeral Elliptic Curve key pair 120 (e.g., ephemeral elliptic curveDiffie-Hellman key pair) or 124 to generate shared values. The publickey 124 corresponding to the label 142 is distributed to those memberswho will have write-only (W/O) access (i.e., the ability to encrypt, butnot decrypt, objects) using that label 142. The private key 120corresponding to the label 142 is distributed to those members who willhave read-write (R/W) access (i.e., the ability to encrypt and decryptan object) using that label 142. Since the public key 124 is derivedfrom the private key 120, as discussed below, write access is implicitlygiven with read access.

The label 142 represents an indexed sequence of key values within adomain. Each value in the sequence represents a particular maintenancestep of the label 142. When a label's key pair value changes, the nextmaintenance value is used. Maintenance values can be changed based on avariety of one or more criteria such as time of day, time since lastchange, number of uses of a key since the last change, etc. At any giventime, preferably only the current maintenance value of the label 142 isused for encryption. Key pair values for any maintenance value can berecovered if the base values for that maintenance value are known.

Whether an entity can recover previous labels, and how far back, isdetermined by the server 41. Some members of the system 30 may be ableto recover back to when they became members, while some all the way backto the first maintenance value, and some members may not be able torecover any previous label key values. Furthermore, this applies to eachindividual label within a specific member role.

Label Private Key Derivation

The label private key 120 for maintenance level j, d_(j), is derived byusing a pseudo-random number generator function 112 with base values114, 116, 118 as seed material. The png function is, e.g., ANS X9.63,Annex A.4.1. There are three original, 512-bit, randomly generated, basevalues 114, 116, 118 that are used to derive the sequence of privatekeys 120 for a label. The base value 114 is called f_(m) (the forwardsecrecy), the base value 116 is called b_(o) (the backward secrecy), andthe base value 118 is called C (the constant). There can be up to mmaintenance values. Thus, the equation for d_(j) is:d _(i) =png(1, r,XKEY _(j) ,XSEED _(j))where r is the order of the point for the chosen curve, B-571 or K-571.XKEY_(j) and XSEED_(j) are functions of f_(j), the forward secrecy basevalue 114 for maintenance level j, b_(j), the backward secrecy basevalue 116 for maintenance level j, and C, the constant base value 118.XKEY _(j) =f _(j) +b _(j)andXSEED _(j) =C+j

The formulae to calculate f_(j) and b_(j) are recursive in nature.f _(j) =H(f _(j+1))_(—) f _(j+1)andb _(j) =H(b _(j−1))_(—) b _(j−1)(2.5)where H(x) is the SHA-512 hash of x. The derivation of theforward-secrecy base value for the first maintenance level involves atotal of m hash operations.

The private key 120 is derived from the forward and backward base values114, 116 and new private keys 120 are derived from hashes of the basevalues 114, 116. Initially, a fixed value for the number of key pairs tobe produced from original base values 114, 116 is set (e.g., m=65,000).The forward and backward base values 114, 116 are hashed 65,000 times,and the n^(th) backward base value (b_(n)) 116 is paired with the(m−n+1) forward base value (f_(m−n+1)) 114. The hashed base values 114,116 are used to produce m private keys and m public keys.

Label Public Key Derivation

Elliptic curve public key points Q_(j) 124 are derived from the basepoint 120 by multiplying by a private key integer 122 generated by theadministration system 32.Q _(j) =d _(j)G (2.6)where Q_(j) 124 is the label public key of maintenance level j, d_(j) isthe private key 120 for the label at maintenance level j, and G is thedomain's base point 122.

The private key 120 and the public key 124 are combined to form a basevalue portion 126 of a label value 137. The label value 137 alsoincludes various parameters/metadata 136 (e.g., the base value and curvefor Elliptical Curve cryptography) and a pedigree 134. The pedigree 134is the result of performing a one-way hashing function 132 on a domainglobally unique identification (GUID) 128 and a label GUID 130. Thedomain GUID 128 uniquely identifies the domain for which the label 142will be assigned. The label GUID is uniquely identified with theparticular label 142 being produced. The pedigree 134 is securely boundto (associated with) the base value 136 of the label value 137. Usingthis technique, the pedigree can be proved for a label (i.e., it can beproved that a specific label came from a specific domain knowing thedomain GUID and label GUID, although knowing the value of a pedigree 134will not allow a determination of the domain).

The label 142 is formed by associating the human-readable name 140 withthe machine-readable portion 138. Further, the label is associated withthe label GUID 130 and is assigned a period (how often to change itsvalue), preferably when the label 142 is produced. The label informationis stored in the database server 43 and is retrievable by the server 41for issuance to specific entities, e.g., the computers 40, 42, 44. Thelabel 142 (or 137) can be stored, e.g., in a magnetic memory, on aCD-ROM, etc., and/or transmitted, e.g., as signals such as electricsignals over a wire, electromagnetic waves wirelessly, optical signals,etc.

The server 41 controls the changing of the label 142. For example, theserver 41 can change which label 142 is the current label 142periodically (e.g., based on time or other measure), based on theoccurrence of one or more events, etc. Preferably, the base valueportion 126 of the label 137 includes an indication of the number of thelabel 142 in the sequence of labels 142.

The server 41 can provide information regarding the base values 114, 116to a requesting member to enable the member to recover previous labelvalues 137. For example, the server 41 can provide to a member abackward base value 116 corresponding to the “earliest” (e.g., in time,in sequence, etc.) label value 137 that the member is allowed torecover. The member can hash this value 116 and combine it with hashedforward base values 114 to determine the appropriate private key 120.The server 41 regulates which previous labels each member can recover(e.g., by storing indicia of what previous labels each member is allowedto recover and only providing information to recover labels that theparticular member is allowed to recover). For example, the server 41 cancontrol recovery of labels 142 to a particular time period, a particulardate, back a particular number of maintenance values, etc.

Further, the server 41 can regulate what labels 142 a member isauthorized to use going forward. The server 41 can control whichcryptographic keys a member will be allowed to use. To regulate this,the server 41 provides the user with the n^(th) hashed forward basevalue 114, thus allowing the member to produce forward base values 114for keys up to the n^(th) key 120. Thus, the server 41 can allow amember to use a label 142 up to a specified criterion (e.g., date,elapsed time, number of uses, etc.).

The server 41 can further limit members to labels values 137 within a“window” of values 137. By providing a member with both a hashed forwardbase value 114 and a hashed backward base value 116 other than theirrespective initial values, the server 41 limits the member to producingprivate keys 120 (and thus public keys 124) for maintenance valuesoutside of the range corresponding to the two hashed base values 114,116 provided. For example, for m=10,000, if the server 41 provides the8001^(st) hashed forward value 114 and the 1,000^(th) hashed backwardvalue 116, then the user can produce private and public keys 120, 124for the range from the 1,000^(th) to the 2,000^(th) key pair (i.e., inthe sequence of key pairs).

Label Splitting

Referring also to FIG. 6, the server 41 is further configured to dividethe machine-actionable label values 138 for storage, and to recreate thelabel values for use, as shown by a process 150 that includes the stagesand components shown. Thus, the encryption key 82 and the decryption key98 (i.e., labels) that are provided at the origination space and at thedestination space may be composed of several components, or splits, eachof which may be provided by a different source. The process 150 isexemplary only and not limiting, e.g., as the process 150 may bealtered, e.g., by having stages and/or components added, removed, orrearranged.

A secure parser process 152 is applied to the label 142 in a manner thatuses an algorithm to divide the label 142 into multiple splits 154, 156,158, 160 so that any single split does not maintain any intelligibleinformation by itself. Each split 154, 156, 158, 160, by itself, isnon-functional (e.g., a benign key), so that the splits 154, 156, 158,160 are useless for indicating a key unless they are recombined usingthe parser process 152 with the corresponding splits 154, 156, 158, 160.

Using an “M” of “N” splitting algorithm in the parser 152, e.g., a 2 of4 split, a domain member can recombine its member label split 160 withany one of the other three corresponding splits 154, 156, 158 to obtainthe usable full label 142. The member's token split 160 can bedesignated as a mandatory piece, where a stored member token 162 or 164must be re-combined with any of the other splits 154, 156, 158 toregenerate the usable full label 142. Recombining the other splits 154,156, 158 without the member's mandatory split 160 will not enable theparser process 152 to recombine the label splits 154, 156, 158 in ausable manner.

Federated Abridged Token Repositories (ATRs) 166 and/or 180 are employedas warehouses of the parsed member label splits 154, 156, 158. Theadministrative system server 41 produces an organization by defining aset of servers/devices referred to as an Abridged Token Repository (ATR)cluster 166. This ATR cluster 166 stores the parsed label splits 154,156, 158. This ATR cluster 166 may be designated as required servers orsimply available servers for the corresponding domain. If the ATRcluster 166 is listed as required, then the servers in the cluster 166are assigned (e.g., automatically) to all labels created within thedomain. If the ATR cluster 166 reflects availability, then a domainsecurity officer may assign any specified servers to the label 142,e.g., when the label 142 is produced. The ATRs can be stored, e.g., onvarious servers throughout the system 30, at a designated URL site forInternet connectivity, and/or on various devices such as laptop ordesktop computers, personal digital assistants (PDAs), softwareprogrammable radios, field-programmable gate arrays (FPGAs), etc.

For the ATR splits 154, 156 and/or 158, once the label 142 is split bythe parser algorithm 152, each split 154, 156, 158 is individuallyencrypted 168 with the public encryption key 124 for a particular domainmember, signed 170 with an organizational digital certificate and pushedout to a specific ATR device in the cluster 166 and/or 180, here(although not required) via an ATR service 172. Thus, the splits 154,156, 158 are unique to a domain member, even if the label 142 isprovided to multiple members. This process is applied for each ATR splitlabel 154, 156, and/or 158 that was produced by the “M” of “N” parserfunction 152. Likewise, the Token Maintenance File (TMF) split 160 isproduced by the parser process 152. The TMF split 160 is encrypted 174with the member's public encryption key (e.g., that is identity basedand unique to the member), signed 176 with an organizational digitalcertificate, and pushed out to a specific TMF service, here via a TMFservice 178. Thus, the split 160 is unique to a domain member, even ifthe label 142 is provided to multiple members. The encrypted splits 154,156, 158, 160 remain protected until they are received by a KeyProtection Module (KPM), described below, for the member with thecorresponding private key to decrypt the label splits 154, 156, 158,160.

The server 41 is responsible for role and label distribution to domainmembers. In accordance with a role assigned to a member, e.g., by anOrganization Unit Authority, each label 142 associated with the role isparsed and packaged as a Token Maintenance File (TMF) that isdistributed to the member's token 162 and/or 164 and also to the label'scorresponding ATR servers 166 and/or 180. If the occasion fordistribution is a maintenance release, then TMFs are preferably producedand distributed automatically for all members who possess the label 142and for the appropriate ATR servers 166, 180. An ATR may reside on anetwork for a Net-Centric environment 182, with potentially multiple ATRservers 166 employed, or the ATR server 180 might be a device such as alaptop, PDA or some other computing device for a Device-Centricenvironment 184. In either case, benign ATR splits 154, 156, 158 arepushed out to the ATR device 166 and/or 180 for storage. The member'ssplit 160 is recombined using the parser algorithm 152 with itscorresponding ATR split 154, 156, 158 in order to be usable forencryption and/or decryption purposes depending upon whether the keypair generated is the public (write-only) key pair or the private(read/write) key pair, respectively.

The administration system 32 may establish a policy that will allow forspecific label(s) 142 to be distributed without using the parser process152. In this case, a full label 190 is encrypted 192 with the member'spublic encryption key, signed 194 with an organizational digitalcertificate (21) and then pushed out, here with a specific TMF service196 and stored on a member's token 198. The non-split label 190 ispreferably used for a tactical environment only. Based on a desiredpolicy, the label 142 can be distributed to specific members via eithersplit labels 154, 156, 158, 160 or a full label 190. Issuing the fulllabel 190 to members carries corresponding issues with respect toupdates and revocations.

Dynamic Updates and Revocation

The system 30 can dynamically update member privileges and/or revokemember access altogether. Revocation prevents access to materialencrypted subsequent to revocation, while allowing access to materialencrypted during a member's period of legitimate access. Once thedecision to revoke is made, new encryption/ decryption access denialshould be as complete and rapid as security risks warrant.

To revoke a member's privileges, e.g., because a token is determined tobe compromised and/or invalid, the administration system 32 removes(revokes) the components of the member's token that are on the ATRs 166and 180 (preferably every ATR on which member splits are stored).Through the use of splitting the label 142 and storing one split 154,156, 158 on the ATR 166 and the other split 160 on the member's token162, revocation is substantially immediate, whether the member's token162 is ever updated or not. Preferably, other administrators cantemporarily suspend a member's privileges, but only the EnrollmentOfficer (EO) can revoke them. The system 30 provides replication andsynchronization of federated ATRs 166.

The TMF service 178 distributes updates to the member token 162.Depending upon the security requirements and implementation, updates canbe provided to the member's token 162 when the member logs on to thetoken, at which time the server 41 (in particular the KPM describedbelow) automatically looks for an update at the designated TMF servicelocation. If updates are found, the member's token 162 is automaticallyupdated. Other than the member performing the log on, this process ispreferably fully transparent to the member.

Alternatively, updates can be pushed to member tokens so that the system30 automatically performs periodic searches for updates from the TMFservice 178 or to produce interrupts that could notify the member'stoken 162 of an update. A notification may or may not be displayed tothe member.

Referring also to FIG. 7, a process 210 for dynamicallyupdating/revoking member privileges includes the stages shown. Theprocess 210, however, is exemplary only and not limiting. The process210 may be altered, e.g., by having stages added, removed, orrearranged. At stage 220, the label 142 is produced by theadministration system 32 as described above with respect to FIG. 5. Atstages 222, 224 the label 142 is assigned to a role and stored in thedatabase server 43. The role is made available to the administrationsystem 32 to decide, at stage 226, whether to change a role assignmentfor a member. The administration system 32 may decide to revoke memberprivileges at stage 230, remove a role from a member at stage 232, orassign a new role to a member at stage 234. If the administratordetermines that no role change is in order, then the process 210terminates at stage 228.

If it is decided to assign a new role to a member, the administrationsystem 32 assigns the new role at stage 234. The database server 43 isupdated at stage 236 and the new label 142 is sent at stage 238 to asecurity module of the administration system 32 to split the label 142at stage 240 as described above with respect to FIG. 6. The TMF split160 is processed and sent electronically to the member's token 162 atstage 242 to update the token with the new split. Likewise, the ATRsplit(s) 154, 156, 158 is(are) sent to one or more ATR devices 166 atstage 244 for storage. Depending upon the deployment requirements, theremay only be one ATR device in the cluster 166 or there may be multipleATR devices providing redundancy and failover, e.g., in case one ATRdevice is non-functional. At stage 246, the parser 152 is used toretrieve the member's token split from its token 162 and the ATR split154, 156, 158 from the ATR 166 to recombine the label 142 for use.

The administration system 32 at stage 226 may decide to revoke and/or toremove a role from a specific member. The system 30 may perform thesefunctions immediately and may do so with or without direct access to themember's token 162. Similar to updating member privileges, the databaseserver 43 is updated at stage 236 and an update is sent at stage 238 toa business tier portion of the server 41. At stage 240, the label issplit into null values, or the splitting may be bypassed, with nullvalues resulting for the TMF and ATR splits 154, 156, 158, 160. Thesplits 154, 156, 158 are sent out with “null” values, effectivelyremoving the split from the respective service. A null TMF split is sentto the member's token 162 as an update and stored at stage 242. Thus,the TMF split is removed from the member's token 162. In the eventadministration system 32 decides at stage 230 to revoke the member fromthe system 30, the TMF token is removed from the member's token 162 atstage 242. An update is also processed and a “null” ATR split 154, 156,158 is sent out to (preferably all) ATR services to which the member isassigned. This effectively updates the member's privileges whether themember receives the TMF split to its token or not. This results becausethe parser 152 must receive both the member token split 160 along withthe ATR split 154, 156, 158 in order to recombine the label 142 for use.“Vaccine” technology can be employed to provide protection againststoring and replay attacks and otherwise manipulating the parserfunction at stage 246 in order to recombine the labels 142 for which themember is no longer authorized. Vaccine provides kernel levelprotection, intercepting system level calls by the operating system tohelp ensure that only the N2K encryption application will be able toperform specific procedure calls and access the memory space 50.

Sensitivity Labels:

The system 30 uses sensitivity levels to control how data are handled.For example, the sensitivity level can dictate the cryptographicstrength of the encryption algorithm, the type of identification andauthentication (I&A) used for a member to gain access to data, thequality of a random number generator used for encryption, integrityrequirements (e.g., digital signatures and time stamps), etc.Sensitivity labels, indicative of sensitivity levels, reside in theorganization-wide domain—one label is assigned per sensitivity level.The administration system 32 assigns sensitivity levels to members. Themember receives the Read/Write sensitivity label for each assignedsensitivity level. Write-Only sensitivity labels are potentiallyavailable to all members in an organization. As shown in FIG. 6,sensitivity labels, as are all labels 142 assigned to a member, aresplit and stored on the member's token 162 and on one or morecorresponding ATRs 166.

Referring to FIG. 8, each Read/Write (R/W) key pair 312, 314, 316, 318is protected with a corresponding token encryption key (tek) 342, 344,346, 348. The tek 342 for encrypting the sensitivity label R/W key pair312 at the highest sensitivity level (e.g., for a top secret sensitivitylevel 332) is generated randomly. The other teks 344, 346, 348 for theother levels 334, 336, 338 are derived from the top tek 342 by using acryptographic one-way function 343, 345, 347. This gives the memberread-down capability yet not read-up capability. The member, however,may be able to write to higher sensitivity levels (write-up capability).The administration system 32 can implement a variety of policies, e.g.,(1) allowing the member access only to the sensitivity level associatedwith the member (and for which the member authenticates), (2) allowing amember to read at the member's level and levels below (of lessersensitivity) the member's level, and/or (3) allowing the member to writeto any level, regardless (independent) of the member's level. The teks342, 344, 346, 348 themselves are further encrypted on the token with akey that is derived from an I&A process associated with thecorresponding level L3 (332), L2 (334), L1 (336), L0 (338). Thus,members can login at level Lx and use corresponding R/W sensitivitylabels 312, 314, 316, 318 at any level Ly where y≦x.

Sensitivity label Write-Only (W/O) key pairs 322, 324, 326, 328 arestored with the category labels at the lowest sensitivity level L0(338), protected with tek0 348. A sensitivity label's public and privatekeys are generated the same as “category” labels. Sensitivity labels arespecial purpose labels that provide an indication of relative value andcategory labels are standard labels that are grouped according tocategory.

During encryption, if sensitivity labels are used within anorganization, one sensitivity label is used. This is combined with othercategory labels as the encrypting member, or the application, intends.More information is provided below with respect to combining labels.

Configurable I&A:

Member identification processes are based upon one or more differenttypes of factors: Knowledge based factors (e.g., PIN or Password),possession factors (e.g., token), and/or biometrics factors. Theadministration system 32 supports multiple factors of identification andauthentication mechanisms such as strong password, various biometricstypes (e.g., fingerprint, facial recognition, etc.) as well as varioustypes of tokens, digital signatures, etc. The administration system 32can select I&A sensitivity levels 330 for domestic organizations. EachI&A sensitivity level 332, 334, 336, 338 has one or more of the I&Afactors associated with that level 332, 334, 336, 338. A different tekvalue 340 is used for each sensitivity level 330. The tek value 340 fora specific sensitivity level 330 is generated by employing a one-wayhash function of the tek value 340 for the sensitivity level 330directly higher in the sensitivity level hierarchy than the one beinggenerated.

A user identification process that uses multiple authentication factors360 is used to combine strengths of factors while preferably avoidingweaknesses of the factors 360. The user identification process isconfigured to implement multiple variations of factor combinations toprovide different access requirements. The access requirementsimplemented by the administration system 32 described here are exemplaryonly and not limiting. For the unclassified level 338, access isavailable using a token 368 as the authentication mechanism 360. Themember logs into (authenticates himself/herself) the token using thetoken 368 and the K_(I&A)0 key 358 is generated. The K_(I&A)0 key 358 isused to unwrap (decrypt) tek0 348 which is used to decrypt the“unclassified” key pairs 318, 328. Access to confidential level 336read/write key pair 316 and write-only key pair 326 is available usingthe token 368 and a password 366 as authentication mechanisms 360. Themember logs into the token using the token 368 and the password 366 andthe K_(I&A)1 key 356 is generated. The K_(I&A)1 key 356 is used tounwrap tek1 346, which is used to decrypt the “confidential” key pairs316, 326 Access to the secret level 324 read/write key pair 314 and thewrite-only key pair 324 is available using the token 368, the password366, and biometrics 364 authentication mechanisms 360. The member logsinto the token using the token 368, the password 366, and the biometrics364 and the K_(I&A)2 key 354 is generated. The K_(I&A)2 key 354 is usedto unwrap tek2 344, which is used to decrypt the “secret” key pairs 314,324. Access to the top secret level 332 read/write key pair 312 and thewrite-only key pair 322 is available using the token 368, the password366, the biometrics 364, and digital signature 362 authenticationmechanisms 360. The member logs into the token using the token 368, thepassword 366, the biometrics 364, and the digital signature 362 and theK_(I&A)3 key 352 is generated. The K_(I&A)2 key 352 is used to unwraptek3 342, which is used to decrypt the “top secret” key pairs 312, 322.The names (top secret, secret, confidential, and unclassified) given tothe sensitivity levels 330 are exemplary only and not limiting.

If the member logs in to the top sensitivity level L3 (332), using theappropriate authentication mechanisms 360 associated with that level332, then the K_(IA)3 key 352 is generated, and the administrationsystem 32 automatically performs the one-way hash function 343, 345, 347to unwrap the lower levels L2-L0 334, 336, 338. If a user logs in atsensitivity level L1 (336), however, the K_(IA)1 key 356 is generated,allowing access to levels L1 (336) and L0 (338), while they willinhibiting reading at levels L2 (334) and/or L3 (332).

Combining Labels

The system 30 can combine labels in order to refine the access controlplaced on encrypted data. Labels may be combined with the logical “AND”and/or “OR” operators. If labels are combined with the logical “AND”operator during encryption, the encrypted data can be decrypted by arecipient that possesses read access for the labels that were combined.If labels are combined with the logical “OR” operator during encryption,the encrypted data can be decrypted by a recipient that possesses readaccess for any one of the combined labels.

In general, combining labels with logical “AND” decreases the readershipof the encrypted data while combining labels with logical “OR” increasesthe readership. Both operators in combination are allowed in accordancewith the invention, giving flexibility in tailoring access control toencrypted data.

Both of these techniques can be used to apply a sort of Boolean logic toaccess control. It is similar to conjunctive normal form (CNF). Labelsin a group are combined with “OR,” and each of these groups is combinedwith “AND.”

Disjunctive Label Sets

The member (or the application) chooses a combining logic for theselected set of encryption labels. This logic resembles disjunctivenormal form (DNF). A disjunctive label set comprises a group of labels,each of which is separated with logical “OR”. The form of the memberdefined logic looks like:(L_(1,1))

(L_(2,1)

L_(2,2)

. . . )

(L_(3,1)

L_(3,2)

. . . ) . . .where L_(1,1) represents a sensitivity label (only one is allowed) andL_(ij) represents the j^(th) label in the i^(th) disjunctive label set.The

symbol represents AND and the

symbol represents OR.

For the chosen set of labels, let d represent the number of disjunctivelabel sets and i_(max) is the number of labels within the i_(th)disjunctive label set. A single disjunctive label set is represented as:(L_(i,1) _(—) L_(i,2) _(—) . . . _L_(i,imax)).

The whole chosen set in DNF type notation is then:$\underset{i = 1}{\overset{d}{⩓}}{\underset{j = 1}{\overset{i_{\max}}{⩔}}L_{i,j}}$

Conjunctive Label Sets

For the system 30 to use this logic, it is transformed into aconjunctive normal form (CNF) type of sentence of the form:(L_(1,1)

L_(2,1)

L_(3,1)

. . . )_(L_(1,1)

L_(2,1)

L_(3,2)

. . . ) . . .

In this form a set of d labels within parentheses are combined with thelogical AND operator. Such a set is called a conjunctive label set(CLS).

The general form of the CNF is:$\underset{k = 1}{\overset{c}{⩔}}{\underset{i = 1}{\overset{d}{⩓}}L_{i,j}}$where c is the total number of derived CLSs and j is a function of theindices i and k.

The value of c is the number of labels in each original disjunctivelabel set multiplied together. Each of the derived CLSs is used tocalculate a different key encryption key (kek) and therefore the dataencryption key will be wrapped c times.$c = {\prod\limits_{i}^{m}i_{\max}}$The index j varies so that all permutations of (i, j) are enumerated.One way to show this mathematically is$j = {\left\lceil {k\quad\left( {{mod}\quad{\prod\limits_{i = j}^{d}i_{\max}}} \right)} \right\rceil.}$where k is the index on the disjunction in the equation for c. Thefollowing illustrates an example of transforming user input, in DNF,into a set that the system 30 can use in CLS form.

User Input in Disjunctive Normal Form:

Is Equivalent to the Conjunctive Normal Form:

Conjunctive Label Set (CLS) 1

Conjunctive Label Set (CLS) 2

-   -   Each CLS is used to derive a wrapping key.    -   Each label in a CLS is used to calculate a shared value.    -   The shared values for labels within a CLS are input to the key        derivation function to derive the wrapping key corresponding to        the CLS.

Key Protection Module

As discussed above, labels can be combined to derive a key to “wrap”(e.g., encrypt) the data encryption key (DeK), with the key to wrap theDeK being unique to each conjunctive label set. If a member of dataencrypted by the system 30 has the private key pairs corresponding tolabels used in one of the conjunctive label sets, then that member isable to unwrap the Data Encryption Key and re-generate originalplaintext data.

Referring to FIG. 9, a process 410 for generating a Key Encrypting Key(KeK) 430, that is used to protect the Data Encrypting Key (DeK) 412,that, in turn, is used to encrypt the plaintext data 402 includes thestages and components shown. The process 410, however, is exemplary onlyand not limiting. The process 410 may be altered, e.g., by having stagesand/or components added, removed, or rearranged.

Generating a Data Encrypting Key (DeK):

In FIG. 9, the DeK 412 is a random value generated directly from arandom number generator (RNG) 414 that here includes a deterministicrandom bit generator (DRBG) 416 that is seeded from a non-deterministicrandom bit generator (NRBG) 418. Generally, the DRBG 416 specified inANS X9.63, Annex A.4.1 is used to generate random values for the system30. The system 30, however, can use a DeK 412 from other sources. Thesystem 30 can incorporate its own RNG 414, or using an RNG API, the DeK412 can be from an external RNG source 414, or an agency/organizationcan provide the DeK 412, etc. RNGs of differing quality can be usedbased upon the environment in which the N2K technology is embedded.

Re-combining Label Splits:

The public-key portions of the benign label splits (see FIG. 6 andrelated discussion), i.e., the member token split 160 and the ATR split154, 156, 158 are “re-combined” in order for them to be used in the KeyProtection Module (KPM) 420. The KPM includes: asymmetric and symmetricalgorithms, with the asymmetric algorithms providing read/write dataseparation and RBAC through a labeling scheme; a key derivation processthat provides a standards-based implementation of protecting symmetrickeys; support for multiple symmetric algorithms (e.g., block or streamcipher) used to encrypt/decrypt data objects; support for multipledomains of users, and; support for server-client, client-device, andclient-only implementations. The label splits are stored on the membertoken 162 and the ATR 166. The member's token split 160 is retrievedfrom the member's token 162 along with the corresponding ATR split 154,156, 158 from the ATR cluster 166. Both the member split 160 and thecorresponding ATR split 154, 156, 158 are provided to the parseralgorithm 152 to be recombined to generate the full label 142. Note,that any member may have more than one label 142 (here n labels) thatare to be re-combined by the parser process 152. The re-combining isrepeated for each label 142 that the member has access to that is beingused in the Conjunctive Label Set.

Generating Shared Values:

During encryption, a set of labels 142 is chosen. For each label 142chosen, a shared value 148 is calculated. Using the example of a singlelabel 142, this is accomplished by multiplying the label's public key(Q) 424 by the ephemeral private key (k) 422. The shared value 426 isthe x-component of the resulting Elliptic Curve (EC) point. This is themethod of ANS X9.63, Section 5.4.1.Z_(j)=deQ_(j)SV_(j)=xz_(j)where Z_(j) is the calculated point, Q_(j) is the public key 146, andSV_(j) 426 is the shared value, all corresponding to the j_(th) label142, de is the ephemeral private key integer 422 and xz_(j) is thex-component of Z_(j). This process is repeated for each label 142 thatis selected for a Conjunctive Label Set for encrypting the plaintextmessage 402. In other words, a unique shared value 426 is generated foreach label 142 in FIG. 9.

Regenerating Shared Values

For decryption, the shared values 426 are regenerated. The label'sprivate key 423 and an ephemeral public key 425 are multiplied together.The shared value 426 is the x-component of the resulting EC point.Z_(j)=d_(j)Q_(e)SV_(j)=xz_(j)where Zj is the calculated point, dj is the private key 423, and SVj isthe shared value 426, all corresponding to the jth label, Qe is theephemeral public key point 425 and xZj is the x-component of Zj. Thisprocess is repeated for each label 142 that is selected for decrypting aciphertext message 404. In other words, a unique shared value isgenerated for each label 142 in FIG. 9.

Deriving the Key Encryption Key

A key encryption key (KeK) 430 is derived for each conjunctive label set142. The shared values 426 along with the GUIDs of the labels 142 in theset are employed to derive the KeK 430.kek=kdf(Z, SharedInfo)where kdf 428 represents the key derivation function of ANS X9.63,Section 5.6.3, using the SHA-512 hash function. The size of the kek1, is256 bits andZ=xz₁kxz₂k . . . kxz_(d)where xZj is the shared value 426 corresponding to the jth label 142 inthe conjunctive set and k is concatenation. The SharedInfo bit string(that provides the label ID and the order in which to process thelabels) isSharedInfo=L₁kL₂k . . . kL_(d)where Lj represents the label id (a globally unique identifier or GUID)for the jth label 142. The shared values 426 and label IDs in these twoequations are in increasing order by label ID. Through this process, aunique KeK 430 is generated for each conjunctive label set selected forthe encryption 434 of the plaintext message 402. In other words, if twodifferent conjunctive label sets are selected by the system 30, twodifferent KeKs 430 will be generated. If three are selected, three KeKs430 will be generated.

For decryption of the ciphertext message 404, the member accesses thelabels 142 corresponding to any one of the conjunctive label sets usedto generate one of the KeKs 430 that were used to encrypt the originalplaintext message 402

Wrapping the Data Encryption Key

The DeK 412 is encrypted using a key wrap function 432 once with eachKeK 430 for each conjunctive label set. For decryption, a member uses aprivate key for each label 142 in any one of the conjunctive label sets.Therefore, the user can decrypt using the wrapped data encryption key412.wK _(i) =W _(keki)(K)where wKi is the data encryption key 412 wrapped with the ith KeK 430,Wkeki is a key wrapping function 432, here the National Institute ofStandards and Technology (NIST) Advanced Encryption Standard (AES) keywrapping function, applied to the DeK 412 using key the KeKi 430, andi=1 to c. Similarly,K=U _(keki)(wKi) (4.7)for unwrapping a wrapped key, where Ukeki is a key unwrap function 432,here the NIST AES key unwrap function, of wKi 433 using the key KeKi430. A wrapped DeK, WDeK, 433 is provided to the encryption algorithm434 and is included in association with (e.g., in a header) theencrypted plaintext data and thus provided as part of the ciphertext404. The WKeK 433 can be unwrapped and used to unwrap the DeK 412 andthus the ciphertext 404 to yield the plaintext 402.

Encryption Process using the Key Protection Module

Referring to FIGS. 4, 6, and 9 the following stages provide theprocedures performed to sign and encrypt data within the client runtimeenvironment of the system 30. This process flow is exemplary only, andnot limiting.

-   -   1. A user (or an application) chooses a symmetric key algorithm        434 to encrypt the plaintext message 402. The DeK 412 can be        provided by any source, typically the RNG 414, to be used by the        algorithm 434. A variety of symmetric algorithms can be used as        the algorithm 434.    -   2. A member is provided access to labels 142, e.g., 142 ₁, 142        ₂, and 142 _(n), that are recombined by the parser function 152.        Member token label splits 160 are retrieved from the member's        token 162 while ATR label splits 154, 156, 158 are retrieved        from the corresponding ATR 166.    -   3. The member (or application) chooses a set of labels 142. The        member uses disjunctive normal form (DNF) to combine the labels        142. Labels 142 for which the public keys are accessible by the        member are available for encryption.    -   4. Based on the labels 142 chosen by the member (or application)        and the combining logic, the labels 142 are re-grouped into        conjunctive label sets. If a foreign key (a public key pair from        an imported label as discussed below) is used, then the shadow        label (a label assigned within the member's (domestic)        organization associated with the imported label) will be “ORed”        with the set of labels 142 selected before generating the        conjunctive label sets.    -   5. A suitable symmetric data encryption key 412 and an        initialization vector 436 are generated randomly from the RNG        414. These may be generated from the same RNG 414, or different        RNGs 414 depending upon the security requirements of the system        30.    -   6. Ephemeral private keys, K^(e), 422 corresponding to each        separate domain spanned by the chosen label set are generated.    -   7. Public keys 424 are calculated for each ephemeral private key        422.    -   8. A shared value 426 for each label 142 is calculated.    -   9. A Key Encryption Key 430 is derived using the key derivation        function 428 for each conjunction from the shared values 426        corresponding to the labels 142 within the conjunction.    -   10. A DeK 412 received from the RNG 414 is wrapped with a KeK        430 using the key wrap function 432 for each conjunctive label        set producing a WDeK 433.    -   11. The plaintext message 402 is digitally signed using the        user's private signing key.    -   12. The plaintext data 402 is encrypted with the chosen        algorithm 434 using the DeK 412 and the initialization vector        436 to produce the ciphertext message 404.    -   13. The ciphertext message 404, digital signature and metadata        are “packaged” (associated with each other) using a secure        hashing function.    -   14. The “package” is signed a second time with the user's        private key.

Decryption

For decryption, a similar, but not identical, process is followed. Theciphertext 404 is received at a destination. The KeK 430 is reproducedusing the private key portion 423 of all the labels corresponding to thepublic portions 422 used to encrypt the plaintext 402. If multiple KeKs430 are used to encrypt the plaintext 402, then any of the KeKs 430 maybe regenerated to decrypt the plaintext 402, with the KeKs 430 beingformed using one or more labels. The DeK 412 is unwrapped by the keywrap function module 432 using the KeK 430. The ciphertext 404 isdecrypted by a decryption algorithm corresponding to the encryptionalgorithm 434 using the DeK 430.

Cross-Domain Cryptographic Key Management for Coalition InformationSharing

Embodiments of the invention provide a variety of features fortechniques for sharing labels. The system 30 includes a centralizedweb/server-based administration system that can update individualmembers upon “logon” and/or through the implementation of interrupts toprovide notice to perform an update. The centralized administrationsystem uses an algorithm based split-key, “parser” 152, capability toprovide near real-time revocation and access privilege updates. Acentralized token repository is provided and further uses federated ATRservers 166 such that there is no single point of failure. The system 30can produce multiple domains within an organization, import/exportlabels with other (e.g., foreign) organizations, and/or producecoalition domains with multiple organizations (e.g., coalitionpartners). This may be accomplished without invoking additionalmanagement overhead on the partners participating in the coalition. Theinvention can be integrated with existing key management infrastructureto provide RBAC technology to provide secure cross-domain informationsharing capability.

Two conventions are provided for supporting cross-domain informationsharing within the system's key management solution: 1) Coalition Domaincomprising many organizations where participating member organizationshave access to read and/or write label pairs (FIG. 10); and 2)Import/Export function for organizations to share public (i.e.,write-only) label pairs with other “foreign” organizations (FIG. 11).The following subsections provide a description of each of thesemethods. Coalition Domains are for larger groups of organizations, e.g.,10 or more organizations. Exemplary groups include militaries, largecommercial groups, etc.

Coalition Domain:

In the system 30, four hierarchical conventions are provided for“sharing” information: Coalitions, Organizations, Domains, and Labels.Referring to FIG. 10, a coalition 510 includes three organizations 512,514, 516. A typical intallation of the administration system 32 will beat an organization level which is generally analogous to a Corporation,DoD, military service, government agency, military command, etc. FIG. 10shows the Organizations 512, 514, 516 participating in the coalition510. The coalition 510 provides a means for cross- or inter-organizationinformation sharing (i.e., Community of Interest) in coalition domains522, 524, 526, while a domestic domains 532, 524, 526 provide forintra-organization information sharing. The coalition domains 522, 524,526 share common domain parameters while the domestic domains 532, 534,536 do not. Cryptographically, the coalition domains 522, 524, 526provide a means of sharing specific information among a consortium ofmembers by distributing cryptographic key pairs (read and write), i.e.,labels, to all members in the coalition 510. Labels are used todiscriminate need-to-know information access or restrictions amongmembers of an organization. The coalition domain provides shared domainparameters, shared read/write labels, member management of its ownorganization (e.g., an organizations domestic (local) administration canmanage coalition domain labels and its own domestic labels), largescalable coalitions, and sub-domains and child domains (explainedbelow).

Organization members (M1-M9) are generally segmented into subgroups 542,544, 546 of Organization Units (OU1-OU3) for both administrative andpractical purposes. Members can belong to one or more domains tofacilitate wider information sharing among other members. A domain isdefined by a set of encryption parameters that “express” a set ofcryptographic keys through a key derivation algorithm implemented by theKPM 420 (FIG. 9).

A coalition is a “super-organization” (COI), both because of itspotential size and because it comprises multiple organizations. In thecase shown in FIG. 10, the coalition comprises the three organizations512, 514, 516, but greater numbers of organizations can participate in acoalition (COI). Further, a single organization may participate inmultiple coalitions. The coalition permits cross-organization,intra-coalition communication while maintaining the autonomy ofparticipating organizations. This is accomplished by sharing one or moredomains (here, the coalition domains 522, 524, 526), along with theircryptographic parameters (e.g., labels and stepping keys along with theElliptic Curve Diffie-Hellman (ECDH) parameters), across participatingorganizations (coalition partners 512, 514, 516) while permitting eachcoalition partner 512, 514, 516 to administer the labels locally(domestically) to their members. Essentially, each coalition partnerorganization 512, 514, 516 possesses a clone of the coalition domain522, 524, 526 that exists in all other coalition partner organizations512, 514, 516. This is accomplished while preserving the scalability for“version” maintenance by means of a Coalition Distribution List (CDL)520 that is maintained at a central administrator (e.g., a central,networked server, such as the administration system 32, that supportsthe coalition 510).

The organization 512 includes the two cryptographic domains 522, 532,and the three Organizational Units shown as OU1A (542 ₁), OU1B (544 ₁),and OU1C (546 ₁). The domestic domain 532 provides a means for theorganization 512 to maintain cryptographic separation from the coalition510 and the other organizations 514, 516. The coalition domain 522 isidentical with regards to cryptographic parameters and system labelsprovided to each of the organizations 512, 514, 516 participating in thecoalition 510. Members M1 and M2 belong to OULA 542 ₁. Members M3through M6 are assigned to OU1B 544 ₁ while Members M7 through M9 are inOU1C 546 ₁. Member management within the organization 512 is performeddomestically by a Domain Security Officer (DSO) 552 and a DSO 562, whoassign roles to Organizational Units 542 ₁, 544 ₁, 546 ₁, that assignsmembers, and various Organization Unit Administrators (OUAs) that managethe OUs and are the administrators responsible for assigning roles toindividual members within respective Organizational Units (OUs) 542 ₁,544 ₁, 546 ₁ within the organization 512. The DSOs produce and manageroles, produce and manage labels, and import/export labels.

The organization 514 includes the two cryptographic domains 524, 534,and the three Organizational Units shown as OULA (542 ₂), OU1B (544 ₂),and OU1C (546 ₂). The domestic domain 534 provides a means for theorganization 514 to maintain cryptographic separation from the coalition510 and the other organizations 512, 516. The coalition domain 524 isidentical with regards to cryptographic parameters and system labelsprovided to each of the organizations 512, 514, 516 participating in thecoalition 510. Members M1 and M2 belong to OU1A 542 ₂. Members M3through M6 are assigned to OU1B 544 ₂ while Members M7 through M9 are inOU1C 546 ₂. The organizations are shown with corresponding OUs havingequal numbers of members, but this is not a requirement as organizationscan have different quantities of members, and corresponding OUs ofdifferent organizations can have different quantities of members.Further, groups of members are shown with multiple members, although amember group may have only one member. Member management within theorganization 514 is performed domestically by a DSO 554 and a DSO 564,who assign roles to Organizational Units 542 ₂, 544 ₂, 546 ₂ and variousOUAs which is the system administrator responsible for assigning rolesto individual members within respective OUs 542 ₂, 544 ₂, 546 ₂ withinthe organization 514.

The organization 516 includes the two cryptographic domains 526, 536,and the three Organizational Units shown as OULA (542 ₃), OU1B (544 ₃),and OU1C (546 ₃). The domestic domain 536 provides a means for theorganization 516 to maintain cryptographic separation from the coalition510 and the other organizations 512, 516. The coalition domain 526 isidentical with regards to cryptographic parameters and system labelsprovided to each of the organizations 512, 514, 516 participating in thecoalition 510. Members M1 and M2 belong to OU1A 542 ₃. Members M3through M6 are assigned to OU1B 544 ₃ while Members M7 through M9 are inOU1C 546 ₃. Member management within the organization 516 is performeddomestically by a DSO 556 and a DSO 566, who assign roles toOrganizational Units 542 ₃, 544 ₃, 546 ₃ and various OUAs which is thesystem administrator responsible for assigning roles to individualmembers within respective OUs 542 ₃, 544 ₃, 546 ₃ within theorganization 515.

To establish the coalition 510, one of the member organizations 512,514, 516 hosts the coalition 510. The other member organizations invitedto participate in the coalition 510 are considered guests. A CoalitionTrust List (CTL) 570 is established by the host and includes a list ofthe organizations participating in the specific coalition 510. The CDL520 provides a means to distribute coalition-specific data (e.g., ECDHcryptographic parameters, Labels, Domain GUID, etc.) to eachorganization 512, 514, 516 participating in the coalition 510. Anorganization public key maintained in the CDL 520 for the organization512 is used to distribute the coalition data to an Executive SecurityOfficer (ESO) 572 for the organization 512. ESOs are configured toimplement organizational structure and to policies. The ESO 572 uses theprivate key of the organization 512 to decrypt the coalition data andassign the decrypted data to the coalition domain 522. The DSO 552 inturn assigns a coalition role to the OU 546 ₁ within the organization512. Similarly, the public key maintained in the CDL 520 for theorganization 514 is used to distribute the coalition data to an ESO 574for the organization 514. The ESO 574 uses the private key of theorganization 514 to decrypt the coalition data and assign the decrypteddata to the coalition domain 524. The DSO 554 in turn assigns acoalition role to the OU 546 ₂ within the organization 514. Likewise,the public key maintained in the CDL 520 for the organization 516 isused to distribute the coalition data to an ESO 576 for the organization516. The ESO 576 uses the private key of the organization 516 to decryptthe coalition data and assign the decrypted data to the coalition domain526. The DSO 556 in turn assigns a coalition role to the OU 546 ₃ withinthe organization 516.

To facilitate scalability, member administration is performed withinspecific organizations and is not inherited by the individual coalitionorganizations 512, 514, 516. The coalition DSOs 552, 554, 556 areassigned by each participating organization 512, 514, 516, respectively,and have the same functions as non-coalition DSOs 562, 564, 566. TheDSOs 552, 554, 556 manage the labels and roles, assigning them to theOUs 542, 544, 546 within their domestic organization. OUAs within theirrespective organizations 512, 514, 516 are responsible for membermanagement (e.g., assigning specific roles to members, etc.). Managementoverhead associated with members is preferably not increased asorganizations are added. A management function is added to support thecoalitions 510, that being the coalition DSO 552, 554, 556 within eachof the respective organizations 512, 514, 516.

The labels provide a means for sharing data within the coalition 510 orcommunity of interest without replacing or eliminating existingidentity-based key management solutions (e.g., PKI) that might alreadybe deployed. Embodiments of the invention can use the existingidentity-based key management solution as a means of authentication todistribute labels to specific individuals/members within a designatedorganization 512, 514, 516.

Multiple Coalitions:

While a domain is an elemental level for administering a cryptographiccommunity, embodiments of the invention provide two subgroups of domainscalled sub-domains and child domains. Both refine granularity, and childdomains convey pedigree as well. Sub-domains can be used as a tool forsegregating information or expressing information autonomy within adomain tree. In addition to resolving pedigree, child domains can beemployed for constraining the propagation of information throughout adomain tree. Sub-domains and child domains are both subsets of largerCOIs, with sub-domain DSOs being able to produce their own labels.

An exemplary coalition might contain a single (coalition) domain. TheCoalition host organization's ESO may associate a broad set of coalitionguest organizations at the coalition level but spread them over avariety of sub- or child-domains, with each organization participatingin one or more coalitions. A domestic clone of the coalition domain isinstantiated within the organization schema of each coalition partnerorganization 512, 514, 516 participating in the specific coalition 510.The convention of assigning organizations at both coalition and domainlevels is both an administrative and reporting aid. The association oforganizations at the coalition, as opposed to the domain level,facilitates the construction of additional domains within thecoalition—all of which is maintained in the CDL 520.

Coalition domains representing COIs may not be entirely identical withregard to the labels and roles they contain. These objects will likelybe organization specific since each coalition organization (e.g., theorganizations 512, 514, 516) has the potential to participate insub-coalition arrangements with other organizations, and consequently,may have labels that are common to a few other, but not all, coalitionorganizations. For example, a broad coalition might encompass the NATOcountries. It may be, however, that a sub-coalition, with a shared labelpair, might be arranged among the United States, Canada, and GreatBritain.

Administrative roles are configured to preserve security and to reduce(if not minimize) and focus responsibilities. In a coalitionenvironment, the benefits of focusing responsibilities and distributingworkload for administrators are facilitated through two conventions fordefining granularity: sub-coalitions and child coalitions.

Sub-Coalition:

A sub-coalition may be employed to accommodate dynamic expansion withina coalition as well as to provide a means of hierarchicaladministration. A sub-coalition may have more than a single domain. Itmay also have its own executive security officer, empowered to createdomains and, potentially, sub-coalitions and child coalitions. This canbe viewed as an extension of a coalition into various, on-going,“phased” efforts to incorporate a variety of emerging coalition groups.As an example, a coalition's initial and primary purpose was anaggressive military action, but once the objective is accomplished,there is a need for an on-going policing action. Additionally, there maybe other “sub-coalitions” that will be involved in areas of humanitarianaid (e.g., staples, medical needs, reconstruction, etc.). These effortsmight involve additional coalition partners with varying joint effortsor operations. Sub-coalitions may be spawned primarily as representinggranularity, or specialization, while additionally providing autonomy.

Child Coalition:

A child coalition is primarily an extension of a child domain on acoalition rather than an organization scale. A distinction between achild coalition and a sub-coalition is that domains in a child coalitiondo not create their own labels. A child coalition domain differs from adomestic child domain in that a child coalition derives its labels from“keys” that may be provided by domestic, foreign, and coalition domains.Thus, it is possible to produce a child coalition domain from one ormore “parent” domains within an existing coalition. It is also possibleto produce a child coalition domain from a label from a coalition domainand from a label received from a foreign organization's domain (althoughthis organization might still be a coalition partner, the domain mightexist only within their organization). It is also possible to produce achild coalition domain from a coalition domain and a domestic domain. Achild coalition provides a means of distributing administrativeresponsibilities while preserving supervision or oversight.

Import/Export:

Referring to FIG. 11, a process 610 for label importing and exportingincludes the stages shown. The process 610, however, is exemplary onlyand not limiting. The process 610 may be altered, e.g., by having stagesadded, removed, or rearranged. Label importing and exporting provides arelatively quick and easy manner for domains from two differentorganizations (e.g., multi-national coalitions, intelligencecommunities, law enforcement agencies from federal, state, and localjurisdictions, etc.) to develop small, ad-hoc coalitions by exchangingwrite-only labels. Label importing and exporting is performed throughcontrol of top administrators (ESOs) 616, 618 from each organization612, 614, respectively. The ESO 616 of the organization 612 identifies adomestic domain 622 within the organization 612 and exchanges signedorganizational public encryption keys with the ESO 618 from theorganization 614. The ESO 616 puts these public organizational keys anda list of foreign DSO 624 in its own Certificate Trust Lists within itsdomestic system database 43. Once this has been established, the DSO 626is allowed to dynamically exchange labels with specified domains 628 ofthe foreign organization 614 as desired on an ad hoc basis.

FIG. 11 provides an example of domains within different organizations612, 614 importing/exporting labels to communicate. When the domain 622of the organization 612 wants to communicate securely with the domain628 of the organization 614, then in response to a request from thedomain 622 the domain 628 sends the public key pair 124 of one of itslabels (e.g., a W/O label) to the domain 622. The domain 628 is said tohave exported this label to the domain 622, and the domain 622 is saidto have imported the label. The (domestic) domain 622 associates one ofits own read/write label key pairs (called a domestic label) to theimported label from the (foreign) domain 628. The domestic labelassociated with an imported foreign label is called a shadow label.

Referring also to FIG. 12, a process 660 for importing and exportingsystem labels between two different organizations and assigning a“shadow” label for data recovery within their domestic organizationincludes the stages shown. The process 660, however, is exemplary onlyand not limiting. The process 660 may be altered, e.g., by having stagesadded, removed, or rearranged. In this example, a member within theorganization 612 can encrypt a plaintext message that a member withinthe organization 614 can decrypt to produce a plaintext messagecorresponding to the original.

At stage 662, the ESO 616 from the organization 612, signs, and sendsthe public portion of its organizational cryptographic key to theorganization 614. The organization 614 encrypts a label 1 at stage 664using the public key of the organization 612 that is maintained in thedistribution list of the organization 614. The DSO 624 from theorganization 614 exports, at stage 667, the write-only public key pairof label 1 as indicated at 668. The administration system 32 (FIG. 1) isconfigured to allow exporting of write-only labels 124 and to prevent orinhibit exporting of private key pairs 120 of labels indicated at 670.

At stage 672, the DSO 626 of the organization 612 imports the encryptedexported label public key pair 668 from the organization 614 using theorganization's private key pair of the organization 612. Thus, theorganization 612 can decrypt the label 1 as indicated at 674 provided bythe organization 614. At this point, the DSO 626 of the organization 612assigns the private 120 and public 124 values of a domestic label A asindicated at 676 as a “shadow” label to the label 674. A role isassigned to the label “set” comprising the imported public key pair 124of the label 674 and the public/private key pairs 124/120 of the label A676. The role is assigned by the DSO 626 to Organizational Units 630,632 within the organization 612. Organization Unit Administrators foreach OU in turn can assign the role with the imported label 674 tomembers 634 and/or 636 within the respective OUs 630, 632. Members withthe appropriate roles assigned with the imported label 674 are able toencrypt a plaintext message that can be decrypted by members 638 and/or640 in the organization 614 that have the corresponding private key pairto the label.

Referring also to FIG. 13, a process 680 for a member from theorganization ABC using the imported label 674 to encrypt a plaintextmessage 682 so that a member from the foreign organization 614 candecrypt the encrypted plaintext includes the stages shown. The process680, however, is exemplary only and not limiting. The process 680 may bealtered, e.g., by having stages added, removed, or rearranged. A memberfrom the organization 612 encrypts, at stage 684, the plaintext message682 to produce ciphertext indicated by 686 using the imported label 1indicated by 674 from the organization 614. The KPM 420 (FIG. 9)automatically implements a mandatory Boolean OR-ing function to generatesecond key encrypting key (KeK) 430, as described above, for the sameplaintext message 682. Consequently, there are two KeKs 430 bound to theheader of the ciphertext message 686. The ciphertext message 686 isreceived by members of the organizations 614, 612 that have the roleswith the corresponding private key pairs for the label 1 indicated by688 and the label A private key 690, respectively. The member from theorganization 614 uses the corresponding label 1 private key pair 670 todecrypt the ciphertext message 686, at stage 694, in order to generate aplaintext message 692 representative of the original plaintext message682. Similarly, a member from the organization 612 that has thecorresponding label 1 private key pair 690 can decrypt the ciphertextmessage 686, at stage 696, in order to produce a plaintext message 698that is representative of the original plaintext message 682. Contraryto public/private key cryptography such as PKI or PGP, the public andprivate key pairs are assigned to system labels rather than to people.

When members use labels within their domestic domain, they can usecorresponding imported W/O labels 674 from the other foreign domainsthrough the association provided by their respective DSO. The member canselect the corresponding imported W/O label 674 or not select it, butpreferably cannot assign any imported W/O label 674 to any otherdomestic R/W label with which it was intended to be associated. Theimported foreign W/O label 674 is associated with a domestic “shadow”R/W label 676 and the member can use these associated labels to decryptthe encrypted information from within the member's domain. The data thatwas encrypted using the W/O label 674 from the foreign domain, can bedecrypted by the foreign domain's members that have the correspondingread label 670. Thus, information can be shared across domains withoutgiving members from other domains access to information other than whatwas intended to be shared within your own domestic domain. To provideinformation sharing across domains from outside organizations, themember selects the data/information to be shared and encrypts the datawith the foreign W/O label 674.

When a member within a domain wants to encrypt data that members in aforeign domain can read, the imported label from the foreign domain isused. The shadow label 676 associated with this imported label 674 isalso used (mandatory OR-ing function is part of the use of the importedlabel and is transparent to the member). This means that the DEK will beencrypted at least twice—once with the foreign label 674 and once withthe shadow label 676. This uses two different wrapped DEKs as well astwo different ephemeral keys, since different Elliptic Curve Domainparameters are being used for each OR-ing function. There is preferablyno limit to the number of labels from foreign domains that can be OR-edtogether to allow sharing information among various foreign domains. Theencrypted object's header, however, will grow linearly for each OR-ingfunction employed.

Other embodiments are within the scope and spirit of the invention. Forexample, due to the nature of software, functions described above can beimplemented using software, hardware, firmware, hardwiring, orcombinations of any of these. Features implementing functions may alsobe physically located at various positions, including being distributedsuch that portions of functions are implemented at different physicallocations.

Further, while the description above refers to the invention, thedescription may include more than one invention.

1. A system for regulating access to information of different levels ofsensitivity, the system comprising: an input configured to receiveauthentication information from a user; and a processor configured to:produce a first token key; encrypt a read-write portion of a firstcryptographic key associated with a first sensitivity level using thefirst token key; encrypt the first token key using first authenticationinformation associated with the first sensitivity level; produce asecond token key by applying a one-way function to the first token key;encrypt a read-write portion of a second cryptographic key associatedwith a second sensitivity level using the first token key, the secondsensitivity level being lower than the first sensitivity level; andencrypt the second token key using second authentication informationassociated with the second sensitivity level.
 2. The system of claim 1wherein the processor is further configured to: decrypt the first tokenkey using the first authentication information; and decrypt theread-write portion of the first cryptographic key using the decryptedfirst token key.
 3. The system of claim 2 wherein the processor isfurther configured to: decrypt the second token key using less than allof the first authentication information; and decrypt the read-writeportion of the second cryptographic key using the decrypted second tokenkey.
 4. A computer program product for regulating access to informationof different levels of sensitivity, the computer program productcomprising computer-readable instructions configured to cause a computerto: receive authentication information from a user; produce a firsttoken key; encrypt a read-write portion of a first cryptographic keyassociated with a first sensitivity level using the first token key;encrypt the first token key using first authentication informationassociated with the first sensitivity level; produce a second token keyby applying a one-way function to the first token key; encrypt aread-write portion of a second cryptographic key associated with asecond sensitivity level using the first token key, the secondsensitivity level being lower than the first sensitivity level; andencrypt the second token key using second authentication informationassociated with the second sensitivity level.
 5. The computer programproduct of claim 4 further comprising instructions configured to causethe computer to: decrypt the first token key using the firstauthentication information; and decrypt the read-write portion of thefirst cryptographic key using the decrypted first token key.
 6. Thecomputer program product of claim 5 further comprising instructionsconfigured to cause the computer to: decrypt the second token key usingless than all of the first authentication information; and decrypt theread-write portion of the second cryptographic key using the decryptedsecond token key.
 7. A method of controlling access to sensitiveinformation, the method comprising: obtaining a first token key;receiving first authentication information associated with a firstsensitivity level and second authentication information associated witha second sensitivity level that is lower than the first sensitivitylevel and thus indicative of less-sensitive information; encrypting aread-write portion of a first cryptographic key associated with thefirst sensitivity level using the first token key; encrypting the firsttoken key using the first authentication information; producing a secondtoken key by applying a first one-way function to the first token key;encrypting a read-write portion of a second cryptographic key associatedwith a second sensitivity level using the first token key; andencrypting the second token key using second authentication informationassociated with the second sensitivity level.
 8. The method of claim 7further comprising: producing a third token key by applying a secondone-way function to the second token key; receiving third authenticationinformation associated with a third sensitivity level that is lower thanthe second sensitivity level; encrypting a read-write portion of a thirdcryptographic key associated with the third sensitivity level using thethird token key; and encrypting the third token key using the thirdauthentication information.
 9. The method of claim 8 wherein the firstone-way function is a cryptographic hashing function and the secondone-way function is the same function.
 10. The method of claim 8 whereinthe second authentication information and the third authenticationinformation are portions of the first authentication information. 11.The method of claim 10 wherein receiving the second authenticationinformation and receiving the first authentication information areincluded in receiving the first authentication information.
 12. Themethod of claim 8 further comprising: re-receiving the secondauthentication information; and inhibiting access to the first tokenkey.
 13. The method of claim 12 further comprising: decrypting thesecond token key using the re-received second authenticationinformation; and decrypting the read-write portion of the secondcryptographic key using the decrypted second token key.
 14. The methodof claim 8 further comprising: re-receiving the first authenticationinformation; decrypting the first token key using the firstauthentication information; decrypting the read-write portion of thefirst cryptographic key using the decrypted first token key; decryptingthe second token key using a portion of the re-received firstauthentication information; and decrypting the read-write portion of thesecond cryptographic key using the decrypted second token key.